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PARTIAL LIST OF STANDARDS ORGANIZATIONS 

HART Communication Foundation (www.hartcomm.org) 
ISA — The International Society of Automation (www. 
isa.org) 

International Electrotechnical Commission/Commission 
Electrotechnique Internationale (www.iec.ch/) 

IEEE — Institute of Electrical and Electronic Engineers 

(www.ieee.org) 

The majority of process equipment such as sensors and trans- 
ducers and final control elements are analog devices and they 
generate or operate on analog signals. In the field of process 
control, automatic control, instrumentation, and communica- 
tion systems the signals can generally be processed in three 
different ways: (1) by analog techniques that directly deal with 
analog signals, (2) by converting the analog signals into digital 
or digital signals to analog and implementing the systems using 
digital instruments, and (3) by dealing with the signals purely 
in digital form as the digital-to-digital inputs and outputs. 

In this chapter, we will provide an overall view of analog- 
and-digital signal transmission techniques and related pro- 
tocols and standards practiced in industrial settings. Typical 
examples will be provided. 


ANALOG SIGNAL TRANSMISSION 
Pneumatic Pressure 

The earliest standardized analog signal transmission mode 
used in industry was pneumatic, and this is still in use in 
many places under special circumstances. The U.S. standard 
is 3-15 psig, corresponding to 0%-100% signal span. The 
“live zero” of 3psi provides linearity around zero signals 
(a negative signal is difficult to handle with a zero-pressure- 
based system). For valve actuation in very simple systems, 
6-30 psig is an alternative allowing smaller actuators for 
the same forces. The European equivalents were originally 
0.2-1 kg/cm 2 , and since the introduction of SI units, 0.2-1.0 
bar/20-100 kPa. All pneumatic equipment is designed to 
have span and zero adjustable to apply any of these signal 


levels. The signal range can be up to 500 m (depending on 
frequency response requirement) and accuracy to ± 0.2%. 

Electric Currents 

On the introduction of electronic instrumentation systems, 
many manufacturers elected to retain the same ratio of an 
elevated zero and a span four times the zero elevation. The 
variety of signals covered current, DC voltage and AC volt- 
age, but practical reasons (including the spread of intrin- 
sic-safe equipment for explosion-hazardous areas) rapidly 
reduced the field to the 4-20 mA DC (ANSI/ISA-50.00.01- 
1975 — R2002) used almost universally for analog current 
(2-wire) signals. The elevated zero provides a minimum 
current to power the transmitter. The current signal is then 
passed through a standard resistor to yield 1-5 V (250 0) or 
0.2-1.0V (62.50), which can fan out to a number of high- 
impedance input users. Three-wire and four-wire transmitters 
sometimes use 0-20 mA, which when converted to 0-10 V 
through a 500 resistor simplifies signal conditioning at the 
expense of bottom-end calibration. This is popular particu- 
larly in European power-station practice. The power require- 
ments for 0/4-20 mA transmitters have shown difficulties 
in remote location systems and together with the growth of 
self-contained wireless transmission systems have caused the 
development of transmitters using 1-5 mV signals, which can 
operate for several years on a single onboard battery. 

Fault Signaling on 4-20 mA 

The NAMUR recommendation NE43 “Standardization 
of the Signal Level for the Failure Information of Digital 
Transmitters” (http://www.namur.de/) outlines, as depicted 
in Table 20.1, a set of signal levels below 4 mA and above 
20 mA, which are widely used. 

There are other applications that use the 0-20 m A range 
to transmit an array of digital data; fire detectors commonly 
use such techniques to pass information on internal diagnos- 
tics as well as warning and alarm levels. 

A not-uncommon problem with many programmable 
logic controller (PLC) systems handling 4-20 m A signals has 
been truncation of the top end — currents exceeding 20 mA 
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TABLE 20.1 

NAMUR Signal Ranges for Nominal 4-20mA Signals 

Condition 

Signal Level mA 

Short-circuit or transducer failed high 

Output >2 1.0 

Overrange 

20.5>0utput>21.0 

Maximum scale 

20.0 

Minimum scale 

4.0 

Under-range 

4.0>Output>3.8 

Transducer detected failure (low) 

3.8>Output>3.6 
(3.7 Nominal) 

Open circuit or transducer failed low 

3.6 > Output 


cause an error in the digital conversion. This makes the 
NAMUR standard unusable and span adjustment difficult. 
Others use a 0-10 V A/D conversion, causing only half the 
nominal resolution to be useful on a 1-5 V signal. 


FREQUENCY-MODULATED SIGNAL SYSTEMS 

While universal in radio communication systems, and com- 
mon in sensor systems, FM signals are not widely used in 
industrial control communication as standardized com- 
munication systems. However, the IEEE 1451 standards, 
which come in seven parts, are largely used for sensor 
communications: 

• IEEE 1451.0 Protocols and format 

• IEEE 1451.1 Information model for smart transducers 

• IEEE 1451.2 Transducer to microprocessor communi- 
cation protocols and transducer electronic data sheet 
(TEDS) formats 

• IEEE 1451.3 Digital communication and TEDS for- 
mats for distributed multi-drop systems 

• IEEE 1451.4 Mixed-mode communication protocols 
and TEDS formats 

• IEEE 1451.5 Wireless communication protocols and 
TEDS Formats 

• IEEE 1451.6 CAN 

• IEEE 1451.7 Transducers 


HYBRID SIGNAL SYSTEMS 

Systems to superimpose digital communications on analog 
channels were developed by several manufacturers (e.g., 
Honeywell, Yokogawa, and Rosemount). Of these, the pre- 
dominant surviving format is the highway addressable remote 
transducer (HART). The HART Protocol was developed by 
Rosemount in the late 1980s and transferred to the HART 
Foundation in the early 1990s. The current (2009) version of 
the HART Protocol is revision 7.2. The “7” denotes the major 
revision level and the “2” denotes the minor revision level. 


HART Protocol is a means for sending and receiving dig- 
ital information across analog wires between smart devices 
and control or monitoring systems. While usually super- 
imposed on analog 4-20 mA loops, it can also be used in a 
multi-drop 20 mA format. 

The HART Protocol implements layers 1, 2, 3, 4 and 7 of 
the open system interconnection (OSI) seven-layer protocol 
model: 

The HART physical layer is based on the Bell 202 
standard, using frequency shift keying to communicate at 
1200bps. The signal frequencies representing bit values of 
0 and 1 are 2200 and 1200 Hz, respectively. This signal is 
superimposed (Figure 20.1) at a low level on the 4-20 mA 
analog measurement signal without causing any interference 
with the analog signal, but is incompatible with NAMUR and 
requires approximately half a volt higher minimum supply 
voltage on the transmitter power to avoid affecting the analog 
current signal at full-scale. 

The HART data link layer defines a master-slave 
protocol — in normal use, a field device only replies when it is 
spoken to. There can be two masters, for example, a control sys- 
tem as a primary master and a handheld HART communicator 
as a secondary master. Timing rules define when each master 
may initiate a communication transaction. Up to 15 or more 
slave devices can be connected to a single multi-drop cable pair. 

The network layer provides routing, end-to-end security, 
and transport services. It manages “sessions” for end-to-end 
communication with correspondent devices. 

The transport layer ensures communications are suc- 
cessfully propagated from one device to another. The trans- 
port layer can be used to ensure end-end communication is 
successful. 

The application layer defines the commands, responses, 
data types, and status reporting supported by the Protocol. 
In the application layer, the public commands of the protocol 
are divided into four major groups: 
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FIG. 20.1 

HART signal superimposed on 4-20 mA analog. (Courtesy of 
HART Foundation, Austin, TX, USA.) 
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1 . Universal commands — they provide functions that 
must be implemented in all field devices 

2. Common practice commands — they provide func- 
tions common to many, but not all field devices 

3. Device specific commands — they provide functions 
that are unique to a particular field device and are 
specified by the device manufacturer 

4. Device family commands — they provide a set of stan- 
dardized functions for instruments with particular 
measurement types, allowing full generic access with- 
out using device-specific commands 

“ WirelessHART ” is a wireless mesh network communica- 
tions protocol for process automation applications. It adds 
wireless capabilities to the HART Protocol while maintain- 
ing compatibility with existing HART devices, commands, 
and tools. 

Each WirelessHART network includes three main 
elements: 

• Wireless field devices connected to process or 
plant equipment. This device could be a device 
with WirelessHART built in or an existing installed 
HART-enabled device with a WirelessHART adapter 
attached to it. 

• Gateways enable communication between these 
devices and host applications connected to a high- 
speed backbone or other existing plant communica- 
tions network. 

• Network manager is responsible for configuring the 
network, scheduling communications between devices, 
managing message routes, and monitoring network 
health. The network manager can be integrated into the 
gateway, host application, or process automation con- 
troller. The network manager determines the redun- 
dant routes based on latency, efficiency, and reliability. 

To ensure the redundant routes remain open and unob- 
structed, messages continuously alternate between the 
redundant paths. Consequently, like the Internet, if a 
message is unable to reach its destination by one path, 
it is automatically re-routed to follow a known-good, 
redundant path with no loss of data. 

The network uses IEEE 802.15.4 compatible radios operat- 
ing in the 2.4 GHz industrial, scientific, and medical radio 
band. The radios employ direct-sequence spread spectrum 
technology and channel hopping for communication security 
and reliability, as well as time division media access synchro- 
nized, latency-controlled communications between devices 
on the network. Each device in the mesh network can serve 
as a router for messages from other devices; a device does not 
have to communicate directly to a gateway, but just forwards 
its message to the next closest device. This extends the range 
of the network and provides redundant communication routes 
to increase reliability. The mesh design also makes adding or 
moving devices easy. As long as a device is within the range 


of others in the network, it can communicate. Readers can 
refer to Chapter 38 for further details on this topic. 

DIGITAL SIGNAL TRANSMISSION 

Digital signal transmission depends on a number of factors: 
The signal itself, the hardware to handle the signals, the 
transmission channels, and the protocols. The signals can be 
transmitted in serial or parallel form in synchronous or asyn- 
chronous modes using a number of modulation techniques or 
in un-modulated forms. In this chapter, we will look at serial 
transmission taking the Modbus as an example. 

Modbus 

In process control applications one of the earliest serial 
protocols, and still widely used in new installations is the 
Modbus®, which is a serial communications protocol first 
published by Modicon (now Schneider Electric) in 1979 
for use with its PLCs. It has remained a de facto standard 
communications protocol in industry, connecting disparate 
suppliers’ equipment. It is now controlled by the Modbus 
Organization, Inc., a membership-based trade association 
(www.modbus.org) who provide a download site. 

The main reasons for the extensive use of Modbus over 
other communications protocols are 

• It is openly published and royalty-free 

• Relatively easy industrial network to deploy 

• It moves raw bits or words without placing many 
restrictions on vendors 

Modbus allows for communication between many devices 
connected to the same network (Figure 20.2) and is often 
used to connect a supervisory computer with a remote ter- 
minal unit (RTU) in supervisory control and data acquisition 
systems. 

Versions of the Modbus protocol exist for serial port and 
for Ethernet and other networks that support the Internet pro- 
tocol suite. Most Modbus devices communicate over a serial 
EIA-485 physical layer (2 -wire [half-duplex] or 4-wire [full 
duplex]). There are many variants of Modbus protocols. 

1. Modbus RTU — This is used in serial communication 
and makes use of a compact, binary representation of 
the data for protocol communication. The RTU format 
follows the commands/data with a cyclic redundancy 
check checksum as an error check mechanism to ensure 
the reliability of data. Modbus RTU is the most com- 
mon implementation available for Modbus. A Modbus 
RTU message must be transmitted continuously with- 
out inter-character hesitations. Modbus RTU messages 
are framed (separated) by idle (silent) periods. 

2. Modbus ASCII — This is used in serial communica- 
tion and makes use of ASCII characters for protocol 
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MODBUS communication 



FID. 20.2 

Typical MODBUS network architecture. ( Courtesy of MODBUS Application Protocol, Hopkinton, MA.) 


communication. The ASCII format uses a longitudinal 
redundancy check checksum. Modbus ASCII mes- 
sages are framed by leading colon and trailing 
newline (CR/LF). 

3. Modbus TCP/IP or Modbus TCP — This is a variant 
used for communications over TCP/IP networks. It 
does not require a checksum calculation as lower layer 
takes care of this. 

4. Modbus over TCP/IP or over TCP — This is a Modbus 
variant that differs from Modbus TCP in that a 
checksum is included in the payload as with Modbus 
RTU. 

5. Modbus Plus {Modbus + or MB +) — An extended ver- 
sion, Modbus Plus (Modbus + or MB+), exists, but 
remains proprietary to Schneider. It requires a dedi- 
cated co-processor to handle fast high-level data link 
control HDLC-like token rotation. It uses twisted pair at 
1 Mbit/s and includes transformer isolation at each node, 
which makes it transition/edge triggered instead of volt- 
age/level triggered. Special interfaces are required to 
connect Modbus Plus to a computer, typically a card 
made for the ISA (SA85), PCI or PCMCIA bus. 

Data model and function calls are identical for the first four 
variants of protocols; only the encapsulation is different. 
However, the variants are not interoperable as the frame for- 
mats are different. 

MODBUS Application Protocol Specification VI. lb is 
available for download from the Modbus organization site 
(www.Modbus-IDA.org); this details the structure in a clear 
and simple manner. 


The standard Modbus function codes are 

• (0x01) Read Coils 

• (Ox 02) Read Discrete Inputs 

• (Ox 03) Read Holding Registers 

• (Ox 04) Read Input Registers 

• (0x05) Write Single Coil 

• (Ox 06) Write Single Register 

• (0 x 07) Read Exception Status (Serial Line only) 

• (Ox 08) Diagnostics (Serial Line only) 

Sub-function codes supported by the serial line devices 

• (Ox 0B) Get Comm Event Counter (Serial Line only) 

• (Ox 0C) Get Comm Event Log (Serial Line only) 

• (0 x OF) Write Multiple Coils 

• (Ox 10) Write Multiple Registers 

• (Oxll) Report Slave ID (Serial Line only) 

• (Ox 14) Read File 

• (Ox 15) Write File Record 

• (Ox 16) Mask Write Register 

• (Ox 17) Read/Write Multiple registers 

• (Ox 18) Read FIFO Queue 

• (Ox 2B) Encapsulated Interface Transport 

• (Ox 2B/0 x 0D) CANopen General Reference Request 
and Response PDU 

• (Ox 2B/0 x 0E) Read Device Identification 

The MODBUS application data unit is built by the client that 
initiates a MODBUS transaction (Figure 20.3). The function 
indicates to the server what kind of action to perform. The 
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FID. 20.3 

Typical MODBUS frame. (Courtesy of MODBUS Application Protocol , Hopkinton, MA.) 


MODBUS application protocol establishes the format of a 
request initiated by a client. 

The function code field of a data unit is coded in one 
byte. Valid codes are in the range of 1-255 decimal (the 
range 128-255 is reserved and used for exception responses). 
When a message is sent from a client to a server device, 
the function code field tells the server what kind of action 
to perform. Sub-function codes are added to some function 
codes to define multiple actions. Function code “0” is not 
valid. 

Sub-function codes are added to some function codes to 
define multiple actions. The data field of messages sent from 
a client to server devices contains additional information 
that the server uses to take the action defined by the func- 
tion code. This can include items like discrete and register 
addresses, the quantity of items to be handled, and the count 
of actual data bytes in the field. 


The data field may be nonexistent (of zero length) in cer- 
tain kinds of requests, in this case, the server does not require 
any additional information. The function code alone speci- 
fies the action. 

The application data unit is built by the client that ini- 
tiates a MODBUS transaction. An error-free transaction is 
shown in Figure 20.4 and transaction with exception report 
is illustrated in Figure 20.5. The function indicates to the 
server what kind of action to perform. The application pro- 
tocol establishes the format of a request initiated by a client. 

The MODBUS command structure offers a variety of 
ways to interact with data. It bases its data model on a series 
of tables that have distinguishing characteristics as shown in 
Table 20.2. 

The distinctions between inputs and outputs, and 
between bit-addressable and word-addressable data items, do 
not imply any application behavior. It is perfectly acceptable, 



FIG. 20.4 

Error-free MODBUS transaction. ( Courtesy of MODBUS Application Protocol, Hopkinton, MA.) 



FIG. 20.5 

MODBUS transaction with Exception report. (Courtesy of MODBUS Application Protocol, Hopkinton, MA.) 
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TABLE 20.2 

MODBUS Data Model 


Primary Tables 

Object Type 

Command Type 

Comments 

Discrete input 

Single bit 

Read-only 

This type of data can be provided by an I/O system 

Coils 

Single bit 

Read-write 

This type of data can be alterable by an application program 

Input registers 

16 -bit word 

Read-only 

This type of data can be provided by an I/O system 

Holding registers 

16 -bit word 

Read-write 

This type of data can be alterable by an application program 


and very common, to regard all four tables as overlaying one 
another, if this is the most natural interpretation on the target 
machine in question. 

For each of the primary tables, the protocol allows indi- 
vidual selection of 65536 data items, and the operations of 
read or write of those items are designed to span multiple 
consecutive data items up to a data size limit that is depen- 
dent on the transaction function code. 

It is obvious that all the data handled via MODBUS (bits, 
registers) must be located in device application memory. But 
physical address in memory should not be confused with 
data reference. The only requirement is to link data reference 
with physical address. MODBUS logical reference numbers, 
which are used in functions, are unsigned integer indices 
starting at zero. 

IEC 61158 Transmission Standard 

The digital signal transmission in industrial environments 
and the associated hardware and software unfortunately is 
still very much dependent on the fieldbuses selected in pro- 
cess control and automation applications. In this respect, the 
history of the “Fieldbus Wars” offers a caution to anyone con- 
sidering development of a universal standard. The history indi- 
cates, what started as an attempt to develop a single Fieldbus 
Standard, by the ISA SP50 committee in 1986, coordinated 
with an IEC committee with purportedly identical aims, rap- 
idly hit the commercial realities of competing national inter- 
ests. Five protocols were proposed, each backed by a number 
of companies. Attempts were made to consolidate the features 
of these protocols and merge them into a single acceptable 
approach — something the ISA users all demanded. Factory 
instrumentation protocol (FIP), which became a French 
national standard, and Profibus, which became a German 
National Standard, both were the prime variants. 

Both the ISA and IEC groups adopted what was then 
known as enhanced performance architecture three-layer 
subset of the seven-layer OSI basic reference model for 
communications. 

The end-user members of the ISA committee went one 
step further, deciding to standardize the semantics of the 
applications that use the underlying communication proto- 
cols to exchange data. This became their so-called “Layer 
8: User Layer,” which has been partially standardized by SC 
65C’s Working Group 7. The IEC fieldbus working group (SC 
65C/WG 6) could not agree to standardize this user layer. 


The three layers that both the ISA and IEC groups could 
agree to standardize were 

• Layer 1: the physical layer that defines the media over 
which, and the signaling by which, communication 
occurs 

• Layer 2: the data link layer that addresses the com- 
munications and detects errors 

• Layer 7: the application layer that formats messages 
for all devices connected to the network 

The user layer, the so-called Layer 8, was described in an 
800-page technical report by the ISA in the early 1990s but 
not standardized by the IEC until 10 years later. 

While the physical layer was standardized in 1992 in 
IEC 61158-2, the data link layer proved to be the area of pri- 
mary disagreement throughout the 1990s, with “very signifi- 
cant technical differences” between the Lrench and German 
approaches. 

The Lrench approach was for a centrally managed dis- 
tributed system with full knowledge of pre-planned system 
load that could maintain strict cycle-to-cycle timing. The 
German approach was for a locally managed distributed sys- 
tem in which nodes attempted to co-operate by inferring the 
overall system load. The Lrench approach was better able to 
handle predictable communication loads such as the state- 
exchange messaging common to process control systems and 
within a distributed PLC. The German approach was better 
able to handle unpredictable loads such as event and alarm 
messages and varying inter-PLC traffic. 

Then there were the commercial problems. Profibus had 
established an early lead over FIP (later WorldFIP) and the 
latter never managed to close the gap in the ensuing struggle 
over market dominance. Later there was a struggle to avoid 
making existing Profibus-based automation products obso- 
lete in the process of standardizing a single compromise pro- 
tocol that included features of both Profibus and FIP. 

On top of that the whole effort was complicated because 
of the European Union’s ability to use CENELEC listing of 
approved standards as a geopolitical tool, because in the EU 
the purchase by regulated industries of unapproved technolo- 
gies is illegal. 

Resolving the issues in 1989, the U.S. convener of the 
IEC fieldbus working group, who was also chairman of the 
parallel SP50 fieldbus committee, had asked the elected edi- 
tor for the future data link layer standard to draft a proposal 
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to include the essence of each technology. The resulting 
compromise, was to allow the two technical approaches to 
co-exist and systems to be “tuned” to function similarly (but 
not identically) to Prohbus or to FIP, or indeed somewhere in 
between. The requested “merger” was achieved. The result 
was desirable, as had been predicted, but workable. In many 
cases, two distinct mechanisms existed to accomplish the 
same goal, but the whole would interoperate no matter how 
the system was configured. 

By the mid-1990s, several strategic alliances among 
fieldbus vendors had formed around a number of communi- 
cation protocol solutions, primarily ISP (based on Profibus) 
and WorldFIP (based initially on FIP but with a commitment 
to adopt the emerging IEC compromise standard). 

The United States, the United Kingdom, and other coun- 
tries continued efforts to unite the battling European parties. 
Vendors made alignments based on perceived technical need 
and then on long-term industrial working relationships, but 
most kept listening to their end users, who told them with- 
out exception that a single worldwide solution was required. 
Thus, their technologists, even when industrial rivalry 
existed, tried to bridge the gap between the two principal 
approaches by offering a series of technical compromises. 

In 1993, major American and Japanese backers of 
Profibus and WorldFIP agreed to attempt a single compro- 
mise that would meet their users’ demands. They agreed to 
adopt a function-block approach based on the ISA SP50 user 
layer technical report, a voluminous document that provided 
the technical basis for open interoperable control of hazard- 
ous processes. As a consequence, they adopted the compro- 
mise data link layer because of its ability to co-schedule 
the communications with the function-block execution — a 
feature from FIP that they determined was necessary. The 
application layer was adapted from that for Profibus. Most 
non-European vendors, and many from Europe, found this 
compromise to be acceptable. Since the compromise data 
link protocol also supported the polling modes and Live List 
of Profibus, vendors from both camps felt that their essential 
needs could be met. Both sides had to adapt and change; 
neither had chips or products ready for market. The result- 
ing protocol, FOUNDATION™ Fieldbus, now dominates 
the worldwide process control market for interconnecting 
smart field devices, just as Profibus dominates the worldwide 
manufacturing automation market for interconnecting smart 
field devices. 

Following the formation of the Fieldbus Foundation con- 
sortium, the battle changed from Profibus versus WorldFIP 
to Profibus versus FOUNDATION Fieldbus. The impasse on 
standardization continued. 

In 1996, CENELEC effectively gave approval to three 
European-led fieldbus protocols: Profibus, WorldFIP, and 
P-NET. Attempts were made to add the American-led pro- 
tocols ControlNet and FOUNDATION Fieldbus to the 
CENELEC list but it was made clear that they would not 
be approved until the threat to the incumbent protocols 
posed by a single international fieldbus standard had been 


resolved. Repeated attempts to reach a single international 
standard failed. Draft after draft got the required percentage 
of “Yes” votes in the IEC, but failed to get sufficiently few 
“No” votes. The prospects for end users worldwide benefit- 
ing from a single international fieldbus standard did not look 
good. Finally, in 1997, ISA SP50 gave up on attempts to stay 
synchronized with the IEC working group and immediately 
voted as standards the compromise protocols for both the 
data link and application layers, which had remained essen- 
tially unchanged since early 1993. 

Multiple Protocols but Worldwide Agreement 

It had become apparent that a single compromise standard 
was unachievable. The long delay in standardization and 
the entrenchment of the various protocols in their markets 
dictated that the only acceptable outcome was multiple 
standards. 

In July 1999, at the urgent request of the 15-member IEC 
Committee of Action (now renamed the Standardization 
Management Board), the IEC fieldbus working group met at 
short notice to try one last time for a compromise. An agree- 
ment was reached to standardize a large number of automa- 
tion protocols under the generic name “fieldbus.” 

All judgment on the merits of competing protocols would 
be suspended; all would be included, provided that they 
were rewritten into a common form using common termi- 
nology based on ISO/IEC 7498, the OSI Basic Reference 
Model for communications. Many in the IEC/SC 65C hier- 
archy opposed this resolution and it was much maligned in 
the press, but it was accepted overwhelmingly when put to a 
hurried vote of the (by then) 40-plus participating National 
Committees. 

The initial edition of IEC 61158, hurriedly assembled in 
only 3 months under the authorization of the system manage- 
ment bus, voted through and published in 2000, specified the 
compromise solution of multiple non-interoperable protocols, 
while the second edition involved only the earlier 61158-2 
physical layer standard and concentrated only on integrating 
various amendments into the base document. So, it was not 
until overwhelming international approval and publication in 
2003 of the 4400-page third edition of the IEC 61158 series 
(Parts 2 through 6, plus the non-normative Part 1 Technical 
Report giving an overview and guidance on the whole fam- 
ily) that the political compromise was truly reflected, with 
seven different protocols listed. 

The standards now cover no fewer than fifteen proto- 
cols, some with Ethernet and non-Ethernet variants, plus 
the corresponding services. Published alongside them is the 
240-page IEC 61784-1, providing guidance for extracting a 
coherent set of interfaces and protocols from the collection 
documented in the IEC 61158 family. Each of the major pro- 
tocol variants backed by the various supplier consortia has a 
corresponding profile. 

These standards therefore describe all of the services and 
protocols, using terminology from the ISO/IEC 7498 OSI 
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TABLE 20.3 

IEC 61158 Listed Fieldbus Families 

CPF Numbers 

Technology Name 

Governing Organization 

i 

FOUNDATION ™ Fieldbus 

Fieldbus Foundation 

2 

CIP™ 

Open DeviceNet Vendor Association, Inc (ODVA) 

CP2/1 

ControlNet™ 

ControlNet International, Ltd. 

CP2/2 

EtherNet/IP™ 

ControlNet International, Ltd. and Open DeviceNet Vendor Association, Inc. 

CP2/3 

DeviceNet™ 

Open DeviceNet Vendor Association, Inc. 

3 

PROFIBUS & PROFINET 

PROFIBUS Nutzerorganisation e.V. (PNO) 

4 

P-NET® 

P-NET User Organisation ApS (IPUO) 

5 

WorldFIP® 

WorldFIP 

6 

INTERBUS® 

Phoenix Contact GmbH & Co. KG./INTERBUS Club. 

7 

Placeholder 


8 

CC-Link /CC-Link LT 

Mitsubishi Electric Co./CC-Link Partner Association 

9 

HART® 

HART Communications Foundation 

10 

Vnet/IP® 

Yokogawa Electric Corporation 

11 

TCnet 

TOSHIBA Corporation 

12 

EtherCAT 

Beckhoff, Verl./EtherCAT Technology Group 

13 

ETHERNET Powerlink 

Bernecker&Rainer Industrieelektronik Ges.m.b.H./Ethemet POWERLINK 



Standardization Group 

14 

ETS 

SUPCON Group Co. Ltd. 

15 

MODBUS-RTPS 

Schneider Automation Inc. 

16 

SERCOS 

Interests Group SERCOS interface e.V. 
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FIG . 20.6 

Wireless industrial network. 
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Basic Reference Model and parallel document structures to 
facilitate comparison among the options. They also provide 
a stable description of all the underlying protocols (each 
of which may have certain advantages for certain users in 
a given application) as a basis for worldwide interoperabil- 
ity, thus reducing the technical barriers to their study and 
implementation. 

The current (2007) edition of IEC TR61 158-1 lists the 
following fieldbuses; IEC61 158-3 has subparts for relevant 
CPF numbers. Table 20.3. Not all those listed have full speci- 
fications, and there are a number in the market, which are not 
(as yet) listed. 

Wireless Transmission 

An important part of digital signal transmission is the mod- 
ern wireless systems as shown in Figure 20.6. In this respect, 
there is much work going in this field and there are many 
commercial products are available. For example, the ISA100 
committee was established by the ISA to address wireless 
manufacturing and control systems in areas including: 

• The environment in which the wireless technology is 
deployed 

• Technology and life cycle for wireless equipment and 
systems 

• The application of wireless technology 

The ISA-100. 11a standard is intended to provide reliable and 
secure wireless operation for noncritical monitoring, alert- 
ing, supervisory control, open-loop control and closed-loop 
control applications. The standard defines the protocol suite, 
system management, gateways and security specifications for 


low-data-rate wireless connectivity with fixed, portable, and 
moving devices supporting very limited power-consumption 
requirements. The application focus addresses the perfor- 
mance needs of applications such as monitoring and process 
control where latencies on the order of 100 ms can be toler- 
ated, with optional behavior for shorter latency. 

To meet the needs of industrial wireless users and opera- 
tors, the ISA-100. 11a standard provides robustness in the 
presence of interference found in harsh industrial environ- 
ments and with legacy non-ISA- 100 compliant wireless 
systems. The standard addresses coexistence with other 
wireless devices anticipated in the industrial workspace, 
such as mobile phones and devices based on IEEE 802. llx, 
IEEE 802. 15x, IEEE 802. 16x and other relevant standards. 
Further, the standard allows for interoperability of ISA-100 
devices. 
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